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ABSTRACT 

In  this  paper  we  present  major  design  considerations  for  the  development 
of  international  computer  mail  protocols.  A  simplified  functional  model  for 
computer  mail  systems  is  introduced  to  serve  as  the  basis  of  the  discussion 
of  the  protocols.  The  general  framework  of  the  Reference  Model  for  Open 
System  Architecture  proposed  by  the  ISO  is  followed  in  the  description  of  the 
computer  mail  protocol  and  design  issues  involved  at  each  layer  of  the  com¬ 
puter  mail  protocol  are  examined.  The  computer  mail  protocol  is  aimed  at 
non-interactive  communication  between  message  system  users. 


INTRODUCTION 


Many  computer-based  message  systems  already  exist  [16]  and  in  the  near 
future  many  more  system  will  be  in  use  by  large  organizations  to  automate 
the  flow  of  messages  among  their  members.  International  standards  are  needed 
to  allow  the  open  interworking  of  message  system  users  in  different  organiza¬ 
tions,  systems  and  countries.  Over  the  last  few  years,  various  studies  have 
been  made  on  the  development  of  comnuni cation  protocols  for  computer  based 
message  systems  [13],  [15],  [17]  and  certain  international  agreements  may 
soon  be  reached.  In  this  paper  we  present  major  design  considerations  for 
the  development  of  such  standards.  Our  approach  is  to  partition  computer 
mail  functions  into  layers  following  the  general  framework  of  the  Reference 
Model  of  Open  Systems  Architecture  proposed  by  the  ISO  [9].  This  layering 
of  functions  permits  a  clean  specification  of  the  standards  needed. 

Section  I  specifies  a  functional  model  for  computer  mail  systems  that 
serves  as  the  basis  for  the  specification  of  the  communication  standards. 

This  model  is  compatible  with  the  one  proposed  by  the  North  American  System 
Environment  Subgroup  of  IFIPW.G.  6.5  [19]  butmakes  a  distinction  between 
communications  within  systems  and  among  systems.  Section  II  describes  the 
requirements  of  protocols  for  computer  mail  and  the  layering  of  the  computer 
mail  protocol  (CMP)  we  propose.  Section  III  describes  the  session  layers  of 
the  CMP.  Section  IV  specifies  the  presentation  layer  of  the  CMP.  Section  V 
specifies  the  management  layer  of  the  CMP.  Section  VI  discusses  the  message 
processing  layer  of  the  CMP.  Section  VIII  summarizes  highlights  of  this 
proposal  and  points  out  those  areas  in  need  for  further  specification. 


> 


2 

I.  A  FUNCTIONAL  MODEL  FOR  COMPUTER  MAIL  SYSTEMS 
A.  Components 

We  model  a  computer  mall  system  by  partitioning  the  system  into  functional 
components*  each  dedicated  to  a  specific  set  of  computer  mail  functions. 

There  are  three  different  types  of  functional  entities  in  the  proposed  model 
[17]:  MAILBOX,  MAILER  and  GATEWAY  MAILER. 

MAILBOX  (MBX)  is  the  entity  responsible  for  the  processing,  storage  and 
retrieval  of  user  messages.  A  mailbox  serves  as  the  interface  between  its 
message  system  user  and  delivery  services.  This  component  consists  of: 

1.  Message  processing  modules  to  compose,  edit,  retrieve  and 
archive  user  messages. 

2.  Communications  software  to  transfer  user  messages  to  and 
from  the  entity  dedicated  to  message  delivery  (the  local 
mailer). 

3.  User  files  where  user  messages  are  permanently  stored  and 
(optionally)  a  personal  directory  with  users'  system  mail¬ 
box  addresses  is  maintained. 

4.  The  message  workspace  where  undelivered  messages  and 
messages  being  composed  are  maintained. 

MAILER  (MLR)  is  the  component  process  responsible  for  the  delivery  of 
messages  to  and  from  a  specific  set  of  mailboxes  and  the  identification  of 
the  system  mailbox  addresses  of  the  recipients  of  the  messages.  The  mailer 
is  formed  by: 

1.  Communication  software  modules  dedicated  to  the  communications  of 
the  mailer  with  its  local  mailboxes  and  other  mailers. 

2.  The  message  buffer  where  messages  to  and  from  local  mailboxes  are 
temporarily  stored. 

3.  The  mailer  directory  database  which  maintains  addressing  infor¬ 
mation  and  time-stamped  records  of  message  deliveries. 

A  mailing  network  is  formed  by  the  union  of  logically  connected  mailers 
and  corresponds  to  a  public  or  private  message  system.  Thus,  mailing  networks 
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(and  their  corresponding  mailers)  could  be  managed  and  owned  by  one  or  more 
organizations. 

GATEWAY  MAILER  (GMR)  is  the  entity  responsible  for  internetwork  commu¬ 
nication.  Each  mailing  network  has  assocated  with  it  a  gateway  mailer,  which 
represents  half  of  the  gateway  between  a  mailing  network  and  any  other  mailing 
network.  A  computer  mail  system  consists  of  a  set  of  interconnected  mailing 
networks.  The  gateway  mailer  is  formed  by: 

1.  Communication  software  modules  to  communicate  the  local  mailing 
network  with  other  mailing  networks. 

2.  The  message  buffer,  where  messages  to  and  from  mailers  in  the 
local  mailing  network  are  temporarily  stored. 

3.  The  gateway  directory  database,  which  maintains  internetwork 
addressing  information  and  time-stamped  records  of  message 
deliveri es. 

B.  System  Operation 

In  our  architecture  delivery  and  addressing  are  functions  transparent  to 
the  message  system  users.  We  define  a  user-level  naming  format  called  the 
NOLS  address  [71,  [8],  which  consists  of  four  fields  that  contain  information 
about  the  recipient  of  a  message,  as  is  shown  in  Table  1.  NOLS  addresses  are 
used  by  message  system  users  to  describe  recipients.  At  the  time  the  sender 
of  a  message  enters  his  message  he  also  enters  a  NOLS  address  with  what  he 
knows  about  the  recipient's  name  and/or  title,  organization,  geographical 
location  and  (perhaps)  message  system.  The  sender  is  not  concerned  with  the 
recipient's  system  mailbox  address  or  how  the  message  is  delivered,  and  the 
system  assists  the  sender  in  identifying  the  system  mailbox  address  from  the 
user-level  description  (NOLS  address)  of  the  recipient. 

Figure  1  shows  in  a  simplified  form  the  steps  followed  to  deliver  a 
message.  Message  delivery  Is  carried  out  In  two  phases:  The  NEXUS  establish¬ 
ment  phase  and  the  message  delivery  phase.  A  NEXUS  is  an  end-to-end  virtual 
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connection  established  between  the  sender's  and  the  recipient's  mailboxes. 

A  NEXUS  address  is  the  specification  of  a  NEXUS  in  the  system  as  is  shown  in 
Table  1.  During  the  NEXUS  establishment  phase  the  system  maps  the  NOLS 
address  (user-oriented  standard)  into  a  NEXUS  address  (system-oriented  stand¬ 
ard)  and  establishes  the  end-to-end  virtual  connection.  The  message  delivery 
phase  consists  of  the  dispatch  of  the  message  through  the  NEXUS. 

In  an  internetworking  environment,  with  tens  of  thousands  of  users, 
several  organizations  and  various  countries  involved,  it  would  not  be  feasi¬ 
ble  or  desirable  to  maintain  the  system  mailbox  addresses  of  all  message 
system  users  in  the  database  of  each  mailer  or  a  centralized  entity.  Con¬ 
sequently,  in  our  model  each  mailer  maintains  only  the  mailbox  addresses  of 
the  users  served  by  that  mailer,  together  with  a  set  of  mailer  addresses 
(pointers)  that  the  mailer  associates  with  user  groups  and  organizations. 

The  NOLS  address  entered  by  a  sender  serves  as  an  identification  query  to 
the  system  for  obtaining  the  correct  system  mailbox  address.  As  is  shown  in 
Fig.  1,  the  procedure  followed  to  resolve  such  a  query  is  a  store-and-forward 
process  in  which  the  NOLS  address  is  forwarded  among  mailers  and  gateway 
mailers  according  to  the  network  (internetwork)  pointers  maintained  in  their 
directory  databases.  When  a  mailer  (gateway  mailer)  receives  a  query,  the 
mailer  (gateway  mailer)  examines  the  fields  of  the  NOLS  address  and  based 
on  its  directory  database  it  decides  whether  to  forward  the  query,  or  to 
reply  with  a  positive  or  negative  acknowledgement.  Once  the  sender's 
mailer  obtains  a  positive  acknowledgement,  the  NEXUS  between  sender's  and 
recipient's  mailboxes  is  created  (Fig.  1)  and  the  message  can  be  delivered. 
Since  users  may  enter  NOLS  addresses  lacking  key  Information,  various  gateway 
mailers  and/or  mailers  may  have  to  be  queried  to  establish  the  NEXUS. 

An  "electronic  envelope"  is  added  to  the  user  message  or  identification 
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query  being  transmitted  that  specifies  the  control  information  needed  for 
correct  routing,  structuring  of  information,  protection  of  users'  privacy, 
billing  and  accounting. 

II.  THE  COMPUTER  MAIL  PROTOCOL  (CMP) 

Today,  office  automation  systems  are  becoming  more  and  more  sophisticated 
with  the  merging  of  techniques  for  the  communication,  processing,  storage  and 
retrieval  of  information  in  office  environments.  However,  the  evolution  of 
these  sytems  has  been  such  that  a  highly  segmented  and  specialized  market 
exists  [161.  Under  such  conditions,  customers  (individuals  and  organizations) 
manage  and  own  message  systems  that  may  differ  from  each  other  in  many 
different  ways.  In  order  to  allow  the  open  interworking  between  message 
system  users  who  access  different  systems,  international  standards  are 
needed.  These  standards  must  specify: 

1.  The  form  in  which  the  dialogue  is  established  between  communicating 
parti es ; 

2.  The  structure  of  the  information  exchanged  between  processes; 

3.  The  form  in  which  the  computer  mail  services  are  managed;  and 

4.  The  message  processing  procedures  implied  in  the  messages 
transmitted. 

This  set  of  standards  constitute  the  computer  mail  protocol  (CMP).  The 
CMP  must  be  such  that: 

1.  It  is  simple  enough  to  be  implementable; 

2.  It  permits  the  communication  with  existing  systems; 

3.  It  supports  all  the  services  needed; 

4.  It  is  extensible,  so  that  new  features  can  be  added  to  it;  and 

5.  It  is  independent  of  implementation  considerations. 

To  specify  the  CMP  we  follow  the  Reference  Model  for  Open  System 

■» 
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Architecture  proposed  by  the  ISO  [9].  The  CMP  extends  the  higher  three 
layers  of  the  ISO  model  [10],  namely:  The  Application,  Presentation  and 
Session  layers.  As  is  shown  in  Figure  2,  the  CMP  is  partitioned  into  four 
layers:  The  Message  Processing  layer  and  the  Management  layer,  which 
together  constitute  the  ISO  application  layer,  the  Presentation  layer, 
and  the  Session  layer.  The  CMP  relies  on  the  existence  of  a  transport 
service  that  permits  the  establishment  of  logical  connections  between  pro¬ 
cesses  in  different  host  computers  to  transfer  arbitrary  messages  in  the 
proper  sequence,  independently  of  the  communication  subnetworks )  being 
used  [3],  [6].  Each  command  of  the  CMP  is  formed  by  a  set  of  three  nested 
headers  that  constitute  the  "electronic  envelope"  of  the  information  to  be 

processed  by  mailboxes,  mailers  and  gateway  mailers.  Such  an  envelope 
provides  all  control  information. 

III.  SESSION  LAYER 

The  session  layer  of  the  CMP  supports  the  dialogue  between  mailboxes, 
mailers  and  gateway  mailers,  and  between  message  system  users  and  their 
mailboxes.  It  adds  computer  mail  services  to  the  bare  transport  service 
used  to  communicate  processes  in  different  hosts.  The  functions  at  this 
layer  are: 

1.  The  establishment  and  termination  of  sessions  (virtual  connections) 
between  presentation  level  entities. 

2.  The  exchange  of  session  identification  information. 

3.  The  establishment  of  session  mode  capabilities,  control  of 
information  transfer  and  negotiation  of  workstation  profiles. 

4.  Error  recovery  and  control. 

In  general,  different  modes  of  sessions  may  be  established  between  users 

and  mailboxes  (full  duplex,  half  duplex),  and  between  mailboxes,  mailers  and 
gateway  mailers  (one-to-one,  one- to-many) .  Because  of  the  non- interactive 
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form  of  communication  supported  in  computer  mail,  a  datagram-oriented  form  of 
communication  can  be  used  to  support  the  dialogue  between  functional  compo¬ 
nents.  With  this  approach  sessions  are  opened  and  closed  with  the  same 
command  used  to  send  the  presentation-level  information  through  the  session. 
Thus,  the  dispatch  of  presentation-level  commands  is  done  by  means  of  data¬ 
grams.  The  reply  to  a  datagram  specifies  what  portion  of  the  command  has 
been  already  received,  so  that  an  error  recovery  procedure  can  be  implemented 
and  failures  at  the  transport  layer  masked.  The  session-layer  header  must 
also  specify: 

1.  A  unique  identifier  for  the  commands; 

2.  The  next  destination  (or  route)  of  the  command; 

3.  The  mailers  (gateway  mailers)  that  have  handled  the 
command;  and 

4.  The  type  of  command  (i.e.,  datagram  or  reply  to 
datagram) . 

Replies  to  datagrams  must  specify  in  addition: 

1.  The  identifier  of  the  command  being  acknowledged. 

2.  The  mailers  (gateway  mailers)  that  handled  the 
command. 

This  information  is  used  to  route  the  datagram  through  various  mailers 
and  gateway  mailers  and  ensure  loop-free  deliveries. 

/* 

IV.  PRESENTATION  LAYER 

Even  though  today's  computer  mail  systems  only  support  text  messages, 
the  merging  of  new  data  conmunications  techniques,  storage  technologies,  and 
processor  and  terminal  technologies  will  allow  future  computer  mail  systems 
to  become  multimedia  communication  tools  which  integrate  text,  digitized 
voice,  fascimile,  graphics  and  (perhaps)  video  within  the  same  message 
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structure.  If  standards  are  not  set  in  advance,  the  usefulness  of  such 
communication  tools  will  be  diminished  as  users  with  different  terminal 
equipment  will  be  unable  to  communicate  with  each  other. 

The  presentation  layer  of  the  CMP  is  necessary  to  allow  the  open  inter¬ 
working  between  heterogeneous  office  workstations  (e.g.  teletypes,  graphic 
terminals,  word  processors)  and  to  permit  the  exchange  of  information  in 
standard  formats  between  mailers,  gateway  mailers  and  mailboxes.  For  such 
purposes,  this  layer  defines  a  set  of  structuring  rules  to  specify  formats 
that  integrate  alphanumeric  text,  digitized  voice,  graphics  and  video  pic¬ 
tures  in  the  messages  exchanged  in  the  system. 

The  presentation  layer  of  our  CMP  relies  on  the  concept  of  virtual 
workstation  which  is  an  extension  of  the  virtual  terminal  concept  [1],  [61. 

The  virtual  workstation  consists  of  a  hypothetical  office  workstation  with 
standard  functional  characteristics  known  by  the  management  and  message- 
processing-  level  processes. 

The  model  of  a  virtual  workstation  consists  of  a  data  structure  which  is 
specified  by  its  dimensions,  the  data  types  it  contains  and  the  operations 
defined  on  it  [6].  The  access  to  the  data  structure  is  asymmetrical,  always 
initiated  by  the  sender's  process.  Each  workstation  is  assigned  a  work¬ 
station  class  and  profiles  based  on  the  functional  characteristics  of  its 
input/output  devices  and  the  available  forms  to  represent  information.  A 
mailbox  maps  the  virtual  workstation  characteristics  defined  in  the  CMP  into 
the  physical  characteristics  of  the  local  workstation  based  on  the  workstation 
class  and  profiles. 

The  presentation  layer  is  carried  out  in  three  phases:  The  negotiation 
phase,  the  data  transfer  phase  and  the  termination  phase.  These  three  phases 
assume  the  existence  of  a  session  between  the  communicating  parties.  The 
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negotiation  phase  allows  the  presentation-level  processes  to  agree  on  a 
particular  structuring  technique.  Once  an  agreement  is  reached,  the  data 
exchange  takes  place  until  no  more  information  is  to  be  transferred,  at  which 
time  the  transaction  is  terminated.  The  negotiation  of  profiles  is  asymmetric, 
with  the  sender's  process  always  being  the  master  of  the  negotiation.  This 
asymmetry  is  suitable  for  Computer  Mail  and  guarantees  that  the  negotiation 
procedure  is  loop-free. 

Profiles  can  be  negotiated  only  when  the  NEXUS  is  being  established. 

That  is,  when  the  identification  query  is  transmitted.  Once  the  NEXUS  is 
established,  no  further  negotiation  is  possible.  The  recipient's  mailbox 
stores  the  message  as  received.  When  the  message  is  retrieved,  those  portions 
that  the  mailbox  cannot  output  are  deleted  and  the  user  is  notified  of  the 
event. 

The  presentation-level  headers  of  the  commands  define  the  virtual  work¬ 
station  class  and  profiles  being  negotiated.  The  header  of  the  replies 
specify  the  class  and  profiles  supported  by  the  recipient's  mailbox.  Inform¬ 
ation  is  structured  in  a  self-identifying  form  by  means  of  a  set  of  data 
types .  A  data  type  is  made  up  of  a  tag  and  a  value  component.  The  tag  com¬ 
ponent  specifies  the  data  type,  its  size,  its  lexical  level  address  [12]  in 
the  message  and  its  attributes.  The  value  component  contains  management- 
level  information.  A  cell  is  the  basic  unit  of  reference  consisting  of  c 
bits.  A  data  type  is  a  string  of  adjacent  cells  that  encodes  a  piece  of 
information.  Table  2  shows  the  eight  data  types  defined  in  the  CMP.  The 
integer  data  type  encodes  control  information  in  a  compact  form.  String 
data  types  are  used  to  integrate  multimedia  information  in  the  same  message. 
These  data  types  have  a  tag  component  describing  the  characteristics  of  the 
integer  or  string,  and  a  value  component  with  the  application  level 
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information.  The  structure  data  type  is  a  heterogeneous  collection  of  data 
types  used  to  structure  messages  (e.g.,  in  pages,  chapters,  sections,  etc.) 
and  organize  messages  (e.g.,  group  various  messages  in  a  message  bag).  A 
management-level  conmand  is  encoded  as  a  structure.  The  array  data  type 
is  used  to  organize  homogeneous  data  types.  The  pointer  data  type  refers 
to  another  data  type  in  the  same  message  or  a  previous  message.  It  is  used 
to  transmit  multi destination  messages  with  low  redundancy. 

The  "type"  subfield  of  the  tag  component  specifies  the  data  type.  The 
lexical  level  address  provides  for  the  identification  of  the  data  type  within 
the  message.  It  consists  of  the  lexical  level  of  the  data  type  and  the  index 
(sequential  number)  of  the  data  type  within  the  level.  The  attributes 
specified  in  the  tags  depend  on  the  techniques  used  to  encode  text,  voice, 
graphics  and  video,  and  may  have  to  be  negotiated.  The  encryption  subfield 
indicates  whether  or  not  the  value  component  of  the  data  type  is  encrypted 
and  what  technique  is  used. 


IV.  MANAGEMENT  LAYER 

The  management  layer  of  the  CMP  manages  the  delivery  of  user  messages 
and  the  distribution  and  maintenance  of  identification  information.  Table  3 
gives  the  seven  commands  defined  in  the  CMP  to  deliver  user  messages,  dis¬ 
patch  identification  queries  and  update  directory  databases.  The  management- 
level  header  contains  the  information  required  to: 

1.  Specify  the  command  to  be  executed. 

2.  Identify  the  sender  and  the  recipient,  and  date  and  time  of 
delivery.  This  information  is  used  to  enforce  closed  user 
groups  (and  user  privacy  in  general),  and  to  establish  "time 
stamps"  of  every  message  delivery  and  identification  query 
processed. 
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Time  stamps  of  transactions  permit  the  system  to  trace  the  message  when 
problems  arise.  In  addition,  they  constitute  an  accurate  source  of  inform¬ 
ation  for  billing  and  accounting  purposes. 

The  information  component  of  a  management-level  command  contains  the 
information  to  be  processed  by  mailboxes  (in  message  deliveries)  or  mailers 
and  gateway  mailers  (in  identification  queries  and  updates).  Table  4  gives 
the  structure  of  the  commands  defined  in  the  management  layer. 

The  establishment  of  a  NEXUS  between  sender's  and  recipient's  mailboxes 
is  carried  out  at  this  layer  in  the  form  described  in  Sec.  I.  As  is  shown 
in  Table  3,  NOLS  addresses  are  distributed  by  IDENTIFY  commands,  and  DELIVER 
commands  are  used  to  dispatch  user  messages.  A  NEXUS  is  an  end-to-end 
virtual  connection  at  the  management  layer  that  relies  upon  sessions  estab¬ 
lished  at  the  session  layer.  Various  NEXUS'S  may  have  to  be  established 
for  the  delivery  of  a  multidestination  messages  and  various  sessions  may  have 
to  be  established  to  support  a  NEXUS  if  the  message  has  to  be  routed  through 
various  mailers  and  gateway  mailers. 

Network  and  system  level  updating  of  the  pointers  maintained  in  the 
directory  databases  of  mailers  and  gateway  mailers  is  done  by  means  of  the 
UPDATE  command  (Table  3),  which  is  dispatched  when  forwarding  mailers  or 
gateway  mailers  detect  erroneously  delivered  commands.  Information  about 
local  users  in  the  mailers'  directory  databases  is  independently  maintained 
by  each  mailer.  End-to-end  error  recovery  from  erroneous  deliveries  is 
supported  by  the  provision  of  the  Transaction-ID  of  the  headers  and  the 
forwarding  of  the  commands  (when  appropriate)  to  the  proper  mailer  or  gate¬ 
way  mailer. 


\ ... 
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VI.  MESSAGE  PROCESSING  LAYER 

The  message  processing  layer  of  the  CMP  comprise  the  functions  of  editing, 
filing  sorting  and  reviewing  messages  at  the  user  MAILBOX.  The  message  pro¬ 
cessing  layer  typically  includes  a  set  of  commands  to  process  textual  inform¬ 
ation.  Various  such  message  processing  applications  have  been  implemented 
[111.  [18].  Since  message  processing  functions  differ  from  system  to  system, 
it  is  not  known  at  this  time  what  standards  are  needed  at  this  layer  or  if 
standards  are  even  needed  at  all.  However,  we  can  identify  a  generic  set 
of  message  processing  functions  that  fit  general  needs.  These  functions  are: 

1.  User  session  establishment  and  termination; 

2.  Information  retrieval; 

3.  Message  editing  and  composition; 

4.  Message  delivery,  forwarding  and  reply; 

5.  Filing  and  archiving  of  information; 

6.  User  help,  documentation  and  training; 

7.  Customization  of  user  interface; 

8.  Billing  and  statistics;  and 

9.  User-level  security. 

VII.  CONCLUSIONS 

In  this  paper  we  have  presented  major  design  considerations  for  the 
development  of  international  standards  for  computer  mail.  We  followed  the 
Reference  Model  proposed  by  the  ISO  to  describe  our  proposed  protocol.  The 
layering  of  the  computer  mail  protocol  into  four  layers  permits  a  clean 
specification  of  the  standards  needed.  The  message  processing  layer  deals 
with  the  functions  of  composing,  filing  and  sorting  of  the  messages.  The 
management  layer  deals  with  the  management  of  message  deliveries  and  the 
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identification  of  system  addresses.  The  presentation  layer  integrates 
multimedia  information  in  the  same  message  and  structures  application-level 
commands.  The  session  layer  Incorporates  computer  mall  functions  to  the 
lower  level  packet  transport  services  and  permits  a  dialogue  between  computer 
mail  processes. 

In  the  future,  more  general  session  and  presentation  layers  may  evolve, 
as  the  development  of  Teletex  protocols  indicates  [2],  and  it  Is  important 
to  identify  standards  for  the  transmission  of  multimedia  Information.  There 
have  been  various  studies  related  to  the  presentation  layer  [13] , [17]  and  the 
management  layer  [17]  of  the  CMP.  However,  there  have  been  few  attempts  to 
provide  solutions  to  the  addressing  problems  that  arise  in  large  internet 
systems  [8],  [15].  This  problem  will  constitute  a  major  design  problem  for 
system  interconnection.  The  specification  of  message  processing  functions 
is  still  an  open  problem,  mainly  because  users  are  just  starting  to  under¬ 
stand  office  automation  and  because  such  functions  are  directly  related  to 
the  purposes  of  the  communication  between  users. 
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Table  1  -  NAMING  AND  ADDRESSING  FORMATS 


FORMAT  TYPE 

COMPONENTS 

NOLS 

address 

<N-f1eld>  <0-field>  <l-field>  <S-f1eld> 

N-field  —  Contains  information  about  the  recipient(s)  of 
the  message  such  as  his  Name  and/or  title. 

0-field  —  Contains  information  about  the  Organization(s), 
group(s)  or  system  server(s). 

L-field  —  Contains  information  about  the  geographical 
location  of  the  organization(s)  or  group(s) 
referred  in  the  0- field. 

S-field  —  Contains  information  about  the  System  which 
offers  the  computer  mail  services  to  the 
recipient(s) • 

Proposed 

3- layer 
system 
mailbox 
address 

[< internetwork  layer>  <intranetwork  layer>  <local  layer>] 

Internetwork  layer- -Con tains  the  name  of  the  network 
specified  according  to  the  system-wide  formats. 

Intranetwork  layer--Contains  the  name  of  the  mailer  in  the 
mailing  network  specified  in  the  internetwork  layer.  The 
mailer's  name  is  specified  according  to  formats  particular 
to  the  network. 

Local  layer— Contains  the  name  of  the  mailbox  in  the  mailer 
specified  in  the  intranetwork  layer.  The  name  of  the 
mailbox  is  specified  according\to  formats  particular  to 
the  mailer. 

NEXUS 

address 

/[sender's  system]  [recipient's  system! | 

^[mailbox  addressj  *  mailbox  address  Jj 

Table  2  -  DATA  TYPE  FORMATS 


— DATE 
TYPE 

FORMAT 

COMMENTS 

INTEGER 

TAG  =  <X> 

VALUE  3  <integer  base-2> 

If  size  field  is  equal  to  0,  the 
value  component  is  defined  to  be 
empty. 

TEXT 

STRING 

TAG  3  <X>  character 
attributes> 

VALUE  3  <character  string> 

Character  attributes  describe: 
character  set  (e.g.,  ASCII),  char- 
acter  appearance  (e.g.,  type  face, 
boldness,  color,  slanting,  size 
underlining)  and  Interspacing. 

AUDIO 

STRING 

TAG  3  <X>  <vocoding> 

VALUE  3  <bit  string> 

Vocodlng  describes  the  parameters 
used  in  the  encoding  technique  to 
digitize  voice  [4]. 

GRAPHIC 

STRING 

TAG  3  <X> 

VALUE  3  <output  commands> 

Output  coimands  specify  the  crea¬ 
tion,  manipulation  and  management 
of  segments  and  units  in  segments 
[5],  [16]. 

VIDEO 

STRING 

TAG  3  <X>  <coding> 
<compression> 
<attr1butes> 

VALUE  3  <b1t  str1ng> 

Attributes  describe  the  dimentions 
of  the  space  where  information  Is 
to  be  shown  and  the  characteristics 
of  the  device  [16],  [17], 

STRUCTURE 

TAG  3  <X>  <element  count> 
VALUE  3  <data  types > 

ARRAY 

TAG  *  <type><lex1cal  ad- 
dress><crypto> 
<dimens1ons>  <size 
dimension  1>  — 

<size  dimension  n 
<nest«d  tagxframing 
attributes > 

VALUE  3  <value  components 
of  data  types > 

Nested  tag  is  the  tag  component  of 
the  homogeneous  data  types  in  the 
value  component.  If  nested  tag3 
text  string,  then  framing  attributes 
describe  the  page  format  where  i  nfor- 
mation  is  to  be  presented.  Other¬ 
wise  field  Is  empty. 

POINTER 

TAG  *  <type>  <lex1cal 
add res s>  <crypto> 
<nested  tag> 

VALUE  3  <referenced  lexical 
address>  <command 
1dentifier> 

The  contents  of  the  value  component 

Is  located  relative  to  other  data 
type.  Nested  tag  Is  used  for  error 
checking,  this  field  and  crypto 
should  be  equal  to  the  tag  fields 
of  the  referenced  data  type. 

Legend:  <X>  *  <type><lex1cal  address ><s1ze><crypto> 
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Table  3  -  BASIC  SET  OF  COMMANDS  FOR  INTERPROCESS  COMMUNICATION 


DELIVER  —  Contains  the  user  message,  together  with  the  NOLS  and 
NEXUS  address  of  both  sender  and  recipient. 

IDENTIFY  -  Contains  the  user  query,  i.e.,  a  NOLS  address  created 
by  the  sender.  It  also  identifies  the  sender  for 
management  purposes. 

ACK-ID  —  Contains  the  positive  reply  to  an  IDENTIFY  command 
with  the  system  mailbox  address  and  NOLS  address  of 
recipient. 

NACK-ID  —  Contains  negative  reply,  possibly  including  a  "list 
of  similar  names". 

ACK-DEL  --  Contains  positive  acknowledgement  to  a  successful 
delivery. 

NACK-DEL  -  Contains  negative  acknowledgement  to  DELIVER  command 
and  is  possibly  due  to  component  failure,  unauthor¬ 
ized  sender,  or  non-existent  mailbox  address. 

UPDATE  —  Calls  for  an  update  in  the  directory  database  and 
contains  time-stamped  information. 


Table  4  -  MANAGEMENT-LEVEL  COMMAND  STRUCTURE 


FIELD 

SUBFIELD 

COMMENTS 

HEADER 

TRANSACTION- ID 

System  address  of  the  two  parties 
(message  system  user  of  system's 
process)  involved  in  the  transaction. 

O-NOLS 

System-generated  description  of  the 
sender  of  the  message,  query  or  update. 

TIME  STAMP 

Date  and  time  of  transmission  of  the 
command. 

COMMAND  TYPE 

Specification  of  the  command  to  be 
executed. 

OPTION  SPECIFICATION 

Specification  of  the  service  requested 
for  the  command. 

INFOR¬ 

MATION 

Contains  message  processing- level  information,  that  is: 
sender's  message,  identification  query,  updating  information, 
or  reply  information. 
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